Skip to content

Antalya 26.6: Support for 'time' type in Iceberg - #2129

Open
zvonand wants to merge 3 commits into
antalya-26.6from
feature/antalya-26.6/pr-1761
Open

Antalya 26.6: Support for 'time' type in Iceberg#2129
zvonand wants to merge 3 commits into
antalya-26.6from
feature/antalya-26.6/pr-1761

Conversation

@zvonand

@zvonand zvonand commented Jul 29, 2026

Copy link
Copy Markdown
Member

Changelog category (leave one):

  • Improvement

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Support for 'time' type in Iceberg, read and write (#1761 by @ianton-ru).

CI/CD Options

Exclude tests:

  • Fast test
  • Integration Tests
  • Stateless tests
  • Stateful tests
  • Performance tests
  • All with ASAN
  • All with TSAN
  • All with MSAN
  • All with UBSAN
  • All with Coverage
  • All with Aarch64
  • All Regression
  • Disable CI Cache

Regression jobs to run:

  • Fast suites (mostly <1h)
  • Aggregate Functions (2h)
  • Alter (1.5h)
  • Benchmark (30m)
  • ClickHouse Keeper (1h)
  • Iceberg (2h)
  • LDAP (1h)
  • Parquet (1.5h)
  • RBAC (1.5h)
  • SSL Server (1h)
  • S3 (2h)
  • S3 Export (2h)
  • Swarms (30m)
  • Tiered Storage (2h)

Cherry-picked from #1761.


Documentation entry for user-facing changes

Solved #1535

This changes time format,.
Was - seconds from midnight:

SELECT * FROM datalake.`namespace.table`

43200

Now - time with microseconds

SELECT * FROM datalake.`namespace.table`

12:00:00.000000

zvonand added 2 commits July 29, 2026 19:29
…next commit)

---
Original cherry-pick message follows:

Merge pull request #1761 from Altinity/bugfix/antalya-26.3/1535_time_type_write_support

Support for 'time' type in Iceberg
# Conflicts:
#	src/Storages/ObjectStorage/DataLakes/Iceberg/IcebergWrites.cpp
#	src/Storages/ObjectStorage/DataLakes/Iceberg/Utils.cpp
#	tests/integration/test_database_iceberg/test.py
Kept antalya-26.6's nullable-partition Avro union handling in
generateManifestFile and routed the PR's Time/Time64 partition-value
encoding through the base branch's `make_value_datum` lambda.

Kept `getAvroLogicalType` from the PR and antalya-26.6's `static`
linkage of `getPartitionField`; dropped test context belonging to
`test_cluster_joins`, which does not exist on antalya-26.6.
@zvonand zvonand added releasy Created/managed by RelEasy antalya-26.6 ai-resolved Port conflict auto-resolved by Claude labels Jul 29, 2026
@github-actions

github-actions Bot commented Jul 29, 2026

Copy link
Copy Markdown

Workflow [PR], commit [24d1ace]

@zvonand

zvonand commented Jul 30, 2026

Copy link
Copy Markdown
Member Author

@blau-ai

@blau-ai

blau-ai commented Jul 30, 2026

Copy link
Copy Markdown
Collaborator

CI triage for #2129

Verdict: 8 failing checks → 1 PR-caused (a clang-tidy nit with a one-line fix), 7 pre-existing/infra. The only thing this PR actually broke is the arm_tidy lint. Everything else fails the same way on the base branch antalya-26.6 (run 30468399078 @ 4359a07, which is this PR's merge base) or is a runner/memory infra flake.


🔴 PR-caused (1) — needs a fix

Build (arm_tidy)job log

src/Processors/Formats/Impl/Parquet/PrepareForWrite.cpp:504:20: error: variable 'converted_scale' is not initialized
  [cppcoreguidelines-init-variables,-warnings-as-errors]
  504 |             UInt32 converted_scale;

arm_tidy builds with WERROR=ON, so the clang-tidy cppcoreguidelines-init-variables diagnostic is fatal. In practice converted_scale is always assigned before use (the else throws), so this is a lint-only issue — it does not affect the functional binary — but it blocks the tidy gate.

Suggested fix (one line):

-            UInt32 converted_scale;
+            UInt32 converted_scale = 0;

Note: every non-tidy Build (...) job showed skipping (build-cache reuse), so arm_tidy was the only job that actually compiled the new code — this is the single blocker introduced by the diff.


🟡 Pre-existing on the base branch (5) — not caused by this PR

Confirmed by running the same suites on antalya-26.6 @ 4359a07 (the merge base), where they already fail:

Check Evidence it's pre-existing
Regression {aarch64,release} iceberg_1 Base fails the identical scenarios: sort key timezone (all transforms), iceberg iterator race condition, swarm examples. None touch the Time64/Avro/Parquet code in this PR.
Regression {aarch64,release} iceberg_2 Fails on base too.
Regression {aarch64,release} s3_export_partition Fails on base (all 4 features).
Regression {aarch64,release} swarms Fails on base (11/12 features, ~1170 scenarios — swarm services not coming up = infra).
Stateless tests (amd_debug, parallel) Fails on base. Single failure here is 03634_autopr_input_bytes_estimationEstimated query execution time (614s) is too long. Maximum: 600 — a slow-runner timeout, unrelated to the diff.

🟠 Infra / flaky (2) — safe to re-run

  • SQLLogic test (passed on base) — not a correctness regression. The server hit its global memory limit and every query cascaded:
    DB::Exception: (total) memory limit exceeded: would use 3.00 GiB ... current RSS: 25.96 GiB, maximum: 3 GiB
    
    RSS 26 GiB against a 3 GiB limit → the 190,317 "failed tests" are all this one memory-limit cascade, and "total tests < minimum" is the run aborting early. Environmental; re-run should recover.
  • Stress test (arm_debug) — failure signature is Timeout exceeded while receiving data from server / Connection refused (localhost:9000) under load. Classic stress flakiness (base failed Stress test (arm_tsan) similarly); nothing in the diff touches server core. Re-run.

Bottom line

The Time64 / Iceberg-time change looks clean w.r.t. CI — no new test failures are attributable to it. Only the arm_tidy lint needs the one-line init above; the rest are pre-existing base-branch redness or infra flakes that a re-run (or a base-branch fix) will clear.

I have the one-line fix ready. How would you like it delivered — a direct commit to feature/antalya-26.6/pr-1761, or a separate PR from a blau/* branch? I won't push until you say which.

🤖 Generated with Claude Code

@ianton-ru ianton-ru self-assigned this Jul 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ai-resolved Port conflict auto-resolved by Claude antalya-26.6 releasy Created/managed by RelEasy

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants